Application Server (AS) originated sessions/transactions with public user identity (PUI) as the originator are routed via Serving Call Session Control Functions (S-CSCFs). Routing from a User Agent Client (UAC) (e.g. AS) to a Session Initiation Protocol (SIP) proxy (e.g. Interrogating (I)-CSFC) is normal routing according to SIP. Moreover, a UAC can route to an outbound proxy in case the routing to the destination is not clear.
With the introduction of standardized presence, messaging, conferencing, and group service capabilities in an IM CN subsystem, there is a need for Public Service Identities (PSIs). These identities are different from the Public User Identities in the respect that they identify services, which are hosted by application servers. In particular, Public Service Identities are used to identify groups. For example a chat-type service may use a Public Service Identity (e.g. sip:chatlist_@(example.com) to which the users establish a session to be able to send and receive messages from other session participants.
Public Service Identities should take the form of a SIP URL or the “tel:”-URL format. The IM CN subsystem should provide the capability for users to create, manage, and use Public Service Identities under control of an AS (Application Server). It should be possible to create statically and dynamically a Public Service Identity. Each Public Service Identity is hosted by an application server, which executes the service specific logic as identified by the Public Service Identity.
The IM CN Subsystem should provide capability of routing IMS messages using a Public Service Identity.
Depending on the service nature, different mechanisms may be used for configuration and routing of PSIs according to an operator preference. When PSIs are created, the uniqueness of a PSI shall be ensured. Whenever possible, routing to/from a Public Service Identity (PSI) should be provided using basic principles used for IMS routing.
The application server hosting the PSI may be invoked as an originating application server. This can be achieved by modifying filter information within the subscription information of the users intending to use the service identified by the PSI. The PSI is then made available to these users. Then, the SIP requests are directed to the corresponding application server hosting the service according to the originating filtering rules in the S-CSCF of the user who is using the service.
However, such statically pre-configured PSIs are only available internally within the IMS of the operator's domain.
Furthermore, the application server hosting the PSI may be invoked as a terminating application server with the AS and related PSIs configured in the home network, e.g. HSS. Such PSIs are globally routable and can be made available to users within and outside the operator domain, and can take the following form:                Distinct PSIs (e.g. my_service@example.com).        Wildcarded PSIs (chatlist_*@example.com): A range of PSIs with the same domain part in the SIP URI is defined using a wildcard indication in the userpart of the SIP-URI. Distinct PSIs can be created or deleted within the wildcarded range by the users using the Ut interface, or by the operator via O&M mechanisms.        
For both the distinct PSIs and wildcarded PSIs, there are two ways to route towards the AS hosting the PSI:                a) The HSS maintains the assigned S-CSCF information and ISC (Reference Point between a CSCF and an Application Server) Filter Criteria to route to the AS hosting the PSI according to IMS routing principles. In this case, the I-CSCF receives SIP requests at the terminating side, queries the HSS and directs the request to the S-CSCF assigned to the PSI. The S-CSCF forwards the session to the application server hosting the PSI according to the terminating ISC Filter Criteria.        b) The home database maintains the address information of the AS hosting the PSI. In this case, the AS address information for the PSI is returned to the I-CSCF in the location query response, in which case the I-CSCF will forward the request directly to the AS hosting the PSI.        
The AS hosting the PSI may originate requests with the PSI as the originating party. For such originating requests, the home IMS network should be capable to perform the following functions:                In case network configuration hiding is to be applied, the request should be routed by using a Topology Hiding Inter-network Gateway (THIG) function in the I-CSCF (referred to as I-CSCF(THIG)) or other techniques to hide the configuration, capacity, and topology of the network from the outside. When an I-CSCF(THIG) is chosen to meet the hiding requirement then for sessions traversing across different operators domains, the I-CSCF(THIG) may forward the SIP request or response to another I-CSCF(THIG) allowing the operators to maintain configuration independence. This means that the last hop within the originating IMS is an I-CSCF (THIG), which processes the request further on and routes it towards the destination network.        Network Domain Security should be used where applicable.        Charging requirements such as providing appropriate accounting and charging functions via the charging entities should be supported.        In case the target identity is a tel: URL, ENUM translation needs to be performed, and the request should be routed based on the translation result.        
Routing from the Originating AS hosting the PSI can be performed as follows:                a) The AS may forward the originating request to the destination network without involving a S-CSCF. If this option is applied where the target identity is a tel: URL, the AS performs an ENUM query and routes the request based on the translation result. ENUM support for an AS is optional. If an AS does not support ENUM, it should be configured to use b) at least in case of tel: URLs.        b) In case the PSI has a S-CSCF assigned, the AS forwards the originating request to this S-CSCF, which then processes the request as per regular originating S-CSCF procedures.        
To prevent fraudulent or unsecure IMS traffic possibly caused by AS originated requests, security and authentication procedures may be performed towards the AS.